home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 17878 < prev    next >
Encoding:
Text File  |  1996-08-05  |  7.0 KB  |  157 lines

  1. Path: news.cube.de!news
  2. From: hhoff@cube.de (Holger Hoffstaette)
  3. Newsgroups: comp.lang.java,comp.lang.c++,comp.lang.smalltalk
  4. Subject: Re: Will Java kill C++?
  5. Date: 17 Apr 1996 22:12:43 GMT
  6. Organization: Cube Informationssysteme GmbH
  7. Message-ID: <4l3qcr$8u3@cubenx.cube.de>
  8. References: <3134D499.653E@ix.netcom.com> <315BFB16.B74@isg.de> 
  9.     <4ku8rq$pav@cubenx.cube.de> <goochb.340.00156E50@rwi.com>
  10. NNTP-Posting-Host: intel1.cube.de
  11. X-Newsreader: RadicalNews (TM) 0.8.5 Beta(i)
  12.  
  13.  
  14. Sorry, a little late..
  15.  
  16. William D. Gooch wrote:
  17. > In article <4ku8rq$pav@cubenx.cube.de> hhoff@cube.de (Holger Hoffstaette) 
  18. writes:
  19. > >William D. Gooch wrote:
  20. > >> 
  21. > >> Gosh, hasn't this been discussed enough before?  MI has 
  22. > >> great value when used appropriately.  Added complexity 
  23. > >> and indirection in instance structures or redundant code 
  24. > >> are essentially the only ways to compensate for its lack. 
  25. > >Yeah, it's also a great way of preventing you from fixing third-party
  26. > >classes that are Broken By Design(tm).
  27. > What do you mean by "preventing?"  MI is an added 
  28. > capability, and prevents nothing that I can think of.
  29.  
  30. Many of the C++ class libraries I've seen that use MI have serious
  31. problems - they either fall over at the slightest tip (trigger one
  32. extended part, see the rest of the heirarchy fall) or, even worse,
  33. are just *wrong* when it comes to the modeled class hierarchy.
  34. I can not 'untangle' the given mess by overriding or 'flattening' the
  35. inheritance hierarchy. Inserting a delegate can get you around this,
  36. but it usually leads to the bloat you mentioned if not done properly
  37. (i.e. carefully); you might end up inserting more delegations than you
  38. planned. SI systems are probably simpler (easier?) in this regard.
  39.  
  40. > >Some of us have *real* protocols & forwarding, and get by great without
  41. > >unnecessary code bloat or weirdo design. MI - thanks, but: No Thanks!
  42. > Certainly you are free to not use MI, whether or not the 
  43. > language supports it.  In my experience, properly used 
  44. > MI helps in avoiding "code bloat," as I pointed out before.
  45.  
  46. 'Properly' used - sure!
  47.  
  48. > "Forwarding" (delegation) is an example of the indirection 
  49. > I was referring to, and what you mean by "*real* protocols"
  50. > is not at all clear.  (Apparently this is something that can't
  51.  
  52. Forwarding is great and IMHO used way too little, maybe because many
  53. people don't know something like it exists, or how easy, yet powerful
  54. it is.
  55.  
  56. By real protocols I meant protocols (interfaces, capabilities) that can
  57. be 'attached' to a class anytime, anywhere; they should be optionally
  58. inheritable, mixable without conflict, addressable and speakable over a
  59. wire (distributed objects). I use Objective-C and it comes pretty close
  60. (which has a lot to do with the environment I'm in (NEXTSTEP), but then
  61. again, that's no coincidence).
  62.  
  63. My Smalltalk is a bit rusty (we -are- wasting c.l.s space, right? :), but
  64. I don't think you can ask an object if it conforms to a certain
  65. protocol/category/whatyoucallit; methods only, if I remember correctly.
  66. No way in C (now that would be fun) or C++. RTTI is little help, asking
  67. for or knowing a 'type' (the word tells) doesn't give me a clue whether
  68. the object I'm talking to actually knows what I'm talking about or not!
  69. I think what I'm trying to say is that capabilities/interfaces are good
  70. and too rigid hierarchies are bad. (cf. the follow-up by Matthias Blume).
  71.  
  72. > be accomplished in a language which supports multiple 
  73. > inheritance?  Very interesting.)
  74.  
  75. I'm not sure if MI in principal prevents something like I described above;
  76. it probably depends on the implementation and method dispatch semantics of
  77. the particular language.
  78.  
  79. > You'll need to define "weirdo design" (is that a technical 
  80. > term?) before I can respond to that part.
  81.  
  82. When Holy Wars get tough, the techies get weirdo.
  83.  
  84. Read: both MI and delegation/forwarding can be used easily to botch up
  85. royally (what's new?). MI can get you in the mud quickly and you can't
  86. get out anymore; excessive delegation can make you sink slowly, but
  87. surely. Your choice. :)
  88.  
  89. I've had my head in large delegation-based systems (ObjC, Smalltalk)
  90. that virtually collapsed because of a system-wide broadcast (delegation)
  91. 'storm' that just never seemed to end, yet was necessary (or *thought* to
  92. be necessary) to keep the system in a consistent state. These I call
  93. 'weirdo' designs, since they usually show that the corresponding project
  94. has gone insane: prime directive #1 is to try to catch up with a design
  95. mistake made in the beginning, although you *know* that it cannot be caught
  96. and fixed without major surgery.
  97.  
  98. > Truly folks, I had no intention of starting a flamefest here.
  99. > I am at a complete loss to understand the vehemence with 
  100. > which some people appear to dislike multiple inheritance.
  101.  
  102. I once had a look at Taligent's 'frameworks', which use(d?) mix-in
  103. classes (probably the most often use for MI) excessively.
  104. The whole thing was about as readable as a brick in the face. IT HURT.
  105. Maybe I was just too dumb for it, but then again, it was probably too
  106. hard for the other 98% of the programming world, too!
  107. It certainly seemed to be too hard for the guy doing the presentation,
  108. trying to explain what it was all about.
  109.  
  110. > My experience with it has been quite good (and I have also
  111. > learned to do fine without it, since I am currently working 
  112. > in Smalltalk).  If there is something substantive behind this 
  113. > very emotional reaction, it has yet to become clear to me.
  114. > If someone can explain this in terms other than "many
  115. > people use MI badly," I would really appreciate it.
  116.  
  117. Today, a disproportionately large amount of code is still written by people
  118. who have no or only insufficient CS education, nor intensive OO training;
  119. they were electricians, salespeople, teachers or physicians in previous
  120. lives, and usually grunt COBOL or VisualBasic (if they're really advanced).
  121. Now that's fine, but letting these people play with MI (preferrably in C++
  122. after a 'Learn The Magic of OO Really Fast In 5 Days Because The Boss Told Us'
  123. is like giving them a bazooka to swat a fly. Granted: this is very emotional
  124. and absolutely no reason for an *objective* view on MI, but it is nevertheless
  125. a very real one. Before someone tells me that this is no reason to take away
  126. the Sharp Knives from The Experts: I agree!
  127.  
  128. Interestingly enough, these more 'naive' users of C++ use MI to simply
  129. add functionality, just like mix-ins. Of course, neither do they know that
  130. they're using mix-ins, nor are the trunk class or its mix-ins properly thought
  131. out, but that has never stopped anybody, right?
  132.  
  133. > I do think there's a serious lack of adequate instruction on 
  134. > the proper use of MI.  Perhaps this can be rectified.
  135.  
  136. I too would certainly like to see some *good* examples where MI fits in,
  137. properly modeling a certain domain problem. Code NOT written in C++ gets
  138. bonus points!
  139.  
  140. By the way: should'n this go into comp.object (only)?
  141.  
  142.  
  143. Regards,
  144.  
  145. Holger
  146. (playing devils' advocate ;)
  147. --
  148.   ___ 
  149.  /\__\  Holger HoffstĪ£tte               net: hhoff@cube.de (MIME, NeXT, PGP)
  150.  \/__/  Cube Informationssysteme GmbH   vox: (+49)0711-90669-0 (or -11)
  151. [kju:b] Stuttgart, Germany              fax: (+49)0711-90669-16
  152.  
  153.